
\subsection*{SDS}

\subsubsection*{UserDocumentation:}
\begin{itemize*}
\item Updated the user documentation to include info on bug tracking
\end{itemize*}


\subsubsection*{Risk-Assessment:}
\begin{itemize*}
\item Updated the risk-assessment document to include more risks
  \begin{itemize*}
  \item Added risk - "Customer wants new features", this risk describes
    the problem where the customer wants new feature late in the development
    cycle. Likelihood, impact, and resolution plans also provided.
  \item Added risk - "Testing failures", this risk describes what actions
    should be taken to prevent testing failures and how to reduce the
    likelihood and impact should they occur.
  \end{itemize*}
\end{itemize*}

\subsubsection*{Diagrams:}
\begin{itemize*}
\item Updated web-design diagram to reflect a few added modules (for
  caching and routing) and interface changes.
  \begin{itemize*}
  \item These changes were made to better separate code into cohesive
    chunks for code mainatinability.
  \item Also, the interface changes came from changes in the web
    platform and core handler.
  \end{itemize*}
\item Updated Android Diagram
  \begin{itemize*}
  \item Android class diagram was changed to show the current activity driven
    design that better conforms to the publisher suggested design pattern
    for Android applications. The design change made other components
    integrate better and allows for full use of the built in phone
    features like the back, home, and menu buttons.
  \item AndroidServer class diagram was updated to include more dependencies
    and better reflect the design of the module such as inner classes. New items
    were added to make the diagram more clear on the different components used.
  \end{itemize*}
\item Updated the database diagram to reflect more closely the actual
  methods and fields being used by each. 
  \begin{itemize*}
  \item Further into the project allowed us to really figure out what functions
  were needed from the database.
  \item The new functions allow for more specific queries that will happen more
  often than some of the more generic queries.
  \end{itemize*}
\item Added the Records diagram to reflect the Java Records being used
  in the system. 
  \begin{itemize*}
  \item We added the Records module to be a representation of 
  the database schema that would be able to be passed between modules
  more easily. This has become very useful to maintain the records
  idea from the database, as well as creates a single data structure
  to hold information. 
  \item The data structure allows for fewer parameters
  to be needed as the parameters are held with the Record Objects. 
  We chose to be able to create hardlinks in between the objects instead
  of just having a primitive field. For example because a ClientSite
  references a Hospital, it actually contains a Hospital Object rather
  than just an int of the Hospital's id field. This causes some issues
  because this makes the objects bulky for passing around, and means 
  more information is needed at the time of creation of the object. In
  response to that, there are a lot more calls to the database to get
  information.
  \item The rationale for doing this was that it was decided
  that it is better to have more information readily available and 
  making all those connections at once instead sequentially means that
  the other modules don't have to worry as much about dealing with 
  getting information from the database. 
  \end{itemize*}
\end{itemize*}

\subsection*{SRS}
\subsubsection*{Process Description:}
\input{process-description-changes.tex}
